繼上篇連網設備的情境，所以我們大概能確認：

1. 目標 IP
2. 目標服務
3. 廠牌\產品\開發商相關資訊

接下來呢，就是針對已知目標連線時的監聽，
這裡我較常用的工具就是 Wireshark，只要針對特定的來源做篩選：

• 顯示特定IP
  　ip.addr == xxx.xxx.xxx.xxx
• 不顯示特定IP
  　ip.addr != xxx.xxx.xxx.xxx
• 顯示特定TCP/UDP Port
  　tcp.port == 80

通常在通訊的時候呢，連網設備在溝通或驗證時，都會傳送明碼帳密或token，
所以就有機會可以做監聽或測聽。

第一次聽見的時候覺得很不可思議，怎麼可能知名品牌的網通設備居然還是用明碼傳驗或是驗證，
但就真的還蠻有趣的啦，反正就多個情境多個應用各種多次的漏洞驗證囉～

範例請參考：

詳細教學文請參考：https://irw.ncut.edu.tw/peterju/course/network/971/doc/homework/09/wireshark.html

我聽見你心底的疑問：怎麼可能現在還有明碼傳輸？
瀏覽器目前都有限制支援TLS版本了，金流或是政府單位也不是都有規定走TLSv1.2了嗎？
這樣側聽是能聽到什麼東西？

沒錯哦！目前的大部份的 Web Security 的傳輸已經很少會用明碼項目去做傳輸了。
除非～是介接的 Web Service、API，與其他系統溝通的模組，可能由於未同時更新或定義，由於這樣的介接項目中，改架構牽一髮而動全身，在漏洞無限，時間有限，優先度可能就排在較後面了…
所以 Web 在介接應用程式或是資料交換作業還是有機會可以看到明碼傳輸。
而且還能透過送出的 Payload 去控制物聯網：

詳細實作：https://www.pentestpartners.com/security-blog/hijacking-philips-hue/

而連網設備其實也有很多產品也有這樣的問題；或許為了要減少加密傳輸的效能，而選用明碼傳輸，或是當初設計沒有考慮這樣的機制，在明碼傳輸的情境下，側錄密碼往往就成了攻擊者進入連網設備的第一個步驟 XDDDD